hooks (React)

Building Custom React Hooks Illustrated.dev

公式ドキュメントの説明が丁寧なので読むことを強く推奨するkadoyau.icon

https://reactjs.org/docs/hooks-intro.html （和訳）

React 16.8で導入された

Hooksを使うと、Class (React)を使わずに、function componentにlocal stateを加えたりできる

モチベーション

ステートフルなロジックをコンポーネント間で再利用するのは難しい

HOCやRender Propを使うとコードの見通しが悪くなる

複雑なコンポーネントは理解しづらくなる

class componentsのlife cycle methodsで処理の凝集度が低くなる

我々はよく、最初はシンプルだったのに、state を使うロジックや副作用によって管理不能なごちゃ混ぜ状態に陥ってしまったコンポーネントをメンテナンスさせられてきました。それぞれのライフサイクルメソッドには、しばしば互いに関係のないロジックが混在してしまいます。例えばとあるコンポーネントは componentDidMount と componentDidUpdae で何かデータを取得しているかもしれません。しかし同じ componentDidMount 内には、イベントリスナーを登録する何か無関係なロジックがあるかもしれませんし、そのクリーンアップのコードは componentWillUnmount に書かれているかもしれません、といった具合です。一緒に更新されるべき互いに関連したコードがバラバラにされ、一方でまったく無関係なコードが 1 つのメソッド内に書かれています。このような状態は簡単にバグや非整合性を引き起こします。

例：https://ja.reactjs.org/docs/hooks-effect.html#tip-use-multiple-effects-to-separate-concerns

テストできなくなる

こういうのが困るので状態管理にReduxとか使うけど、結果として抽象化が過剰になる

Hooksをつかうと凝集度が上がる

クラスは人間と機械の両方を混乱させる

人間：JavaScriptのthisを理解しないといけない

機械：最適化がムズいらしい

classはつらいのでReact.FCをつかって、stateが必要なところはhooksでやろうという流れっぽいkadoyau.icon

Q.フック、クラスのいずれを使うべきですか、あるいはその両方でしょうか？

A. 長期的には、フックが React のコンポーネントを書く際の第一選択となることを期待しています

フックに関するよくある質問 – React

Hookの構文はいろいろある